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Abstract 

Assuring  quality  of  service  (QoS)  requirements  is  crit¬ 
ical  when  assembling  a  distributed  real-time  and  embed¬ 
ded  (DRE)  system  from  a  repository  of  existing  components. 
This  paper  presents  a  two-level  approach  for  assuring  sat¬ 
isfaction  of  QoS  requirements  in  the  context  of  a  reduced 
design  space  for  DRE  systems.  A  dynamic  and  parallel 
approach  is  introduced  to  prune  off  the  infeasible  design 
spaces  at  the  first  level.  Evolutionary  algorithms  cooperat¬ 
ing  with  a  domain-specific  scripting  language  then  discard 
less  probable  design  spaces  using  statistics.  These  tech¬ 
niques  fulfill  the  collective  objectives  of  pruning  and  assur¬ 
ing  the  design  space  at  system  assembly  time. 

1.  Introduction 

Distributed  real-time  and  embedded  (DRE)  systems  are 
widely  used  in  military,  manufacturing,  and  control  systems 
[17].  Many  of  these  systems  consist  of  legacy  components. 
From  the  perspective  of  software  engineering,  there  is  an 
urgent  demand  to  fulfill  the  need  of  the  development,  evo¬ 
lution  and  integration  of  DRE  systems  from  existing  com¬ 
ponents.  This  is  in  the  vision  of  the  UniFrame  project  [16]. 
During  the  synthesis  of  a  DRE  system,  various  appropriate 
components  can  be  selected  from  a  repository.  However, 
numerous  design  and  deployment  decisions  for  the  selected 
components  usually  generate  a  tremendous  number  of  pos¬ 
sible  alternatives  for  constructing  a  DRE  system.  The  de¬ 
sign  information  (i.e.,  specific  design  and  deployment  deci¬ 
sions  and  information  of  involved  components)  required  for 
synthesizing  a  DRE  system  is  called  a  design  space  [13]. 
Among  the  huge  number  of  possible  design  spaces,  many 
of  them,  in  fact,  do  not  satisfy  the  requirements  of  the  DRE 
system  (i.e.,  constraint  satisfaction).  In  addition,  construct- 
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ing  a  DRE  system  (e.g.,  an  avionics  system)  is  naturally 
expensive  and  less  modifiable.  In  order  to  decrease  the  pos¬ 
sibility  of  errors  occuring  after  construction  of  a  DRE  sys¬ 
tem,  validating  a  DRE  system  in  advance  is  also  necessary 
to  conserve  the  future  potential  costs.  Therefore,  it  is  neces¬ 
sary  to  have  a  formal,  manageable,  scalable  and  automatic 
design  space  exploration  approach  to  prune  unsatisfactory 
design  spaces  (i.e.,  unsatisfactory  assembled  cases),  and  to 
validate  the  rest  of  the  assembled  cases  of  a  DRE  system 
from  its  requirements  at  system  assembly  time. 

In  addition  to  functional  requirements,  quality  of  service 
(QoS)  that  pertains  to  the  usage  of  resources  is  an  impor¬ 
tant  requirement  of  DRE  systems.  QoS  parameters  are  used 
to  evaluate  the  degree  of  performance  of  QoS  using  util¬ 
ity  functions,  which  is  the  mathematical  formulas  that  show 
the  utility  of  QoS.  For  example,  timeliness  is  a  quantifiable 
QoS  parameter  that  estimates  whether  the  deadline  is  met  by 
the  addition  of  the  execution  time  of  involved  components. 
Security,  however,  is  a  non-quantifiable  QoS  parameter 
that  evaluates  the  level  of  security  of  a  DRE  system  being 
achieved  with  a  user-defined  function.  This  paper  presents 
a  two-level  assurance  technique,  called  “QoS -UniFrame,” 
for  QoS  of  DRE  systems  assembled  from  components.  This 
technique,  based  on  artificial  intelligence  and  statistics,  re¬ 
duces  the  design  space  and  validates  QoS  requirements  at 
system  assembly  time.  Consequently,  we  believe  that  dis¬ 
carding  infeasible  and  less  probable  cases  at  system  assem¬ 
bly  time  will  require  less  runtime  validation.  In  addition 
to  assurance  and  validation,  QoS-UniFrame  concentrates 
on  observing  and  adapting  non-orthogonal  QoS  parameters 
(e.g.,  CPU  usage  and  throughput)  seldom  addressed  by  re¬ 
searchers.  QoS-UniFrame  also  exploits  Aspect!  [8]  to  pro¬ 
mote  reusability  and  modularity  by  separating  the  source 
code  to  analyze  constraints  from  that  to  construct  design 
spaces.  The  modification  of  the  constraint  analysis  code  is 
convenient  and  isolated  from  the  rest  of  the  source  code. 
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This  paper  is  organized  as  follows:  in  the  next  section, 
background  and  related  work  are  addressed;  section  3  in¬ 
troduces  the  framework  and  techniques  of  QoS-UniFrame; 
section  4  provides  a  case  study;  finally,  we  conclude  and 
point  out  the  future  work  of  the  paper  in  section  5. 

2.  Background  and  Related  Work 

2.1  Background  of  QoS-UniFrame 

The  implementation  of  QoS-UniFrame  is  based  on  two 
techniques  described  in  the  following  subsections. 

2.1.1  Petri  Nets 

System  engineers  need  to  make  various  decisions  while 
constructing  a  DRE  system.  Different  decisions  may  re¬ 
quire  cooperation  with  different  components.  For  one  deci¬ 
sion,  there  may  be  diverse  execution  orders,  execution  time, 
and  events  to  trigger  execution  among  the  chosen  compo¬ 
nents.  Therefore,  there  are  a  huge  number  of  possible  as¬ 
sembled  cases  generated  based  on  different  decisions  and 
components  with  the  consideration  of  various  orders,  time, 
and  events.  QoS-UniFrame  reduces  the  complexity  of  ex¬ 
ploring  all  possible  assembled  cases  for  building  a  DRE  sys¬ 
tem  by  evaluating  their  QoS  requirements.  The  evaluation 
of  QoS  of  a  specific  assembled  case  depends  on  when,  what, 
and  how  the  components  request  QoS  requirements.  When 
expresses  the  specific  time  or  before/after  a  specific  event 
a  component  has  effect  on  a  QoS  parameter;  what  speci¬ 
fies  which  QoS  parameter  is  inspected;  how  represents  the 
relationship  of  data  access  among  the  components. 

In  most  QoS  research  (e.g.,  [13]),  dataflow  analysis  is 
applied  to  explore  possible  solutions  for  assurance  of  QoS 
requirements.  A  segment  of  a  dataflow  is  a  directed  arrow 
between  two  (sets  of)  components  generated  by  a  single  de¬ 
cision.  The  directed  arrow  means  that  two  (sets  of)  compo¬ 
nents  have  requests  to  access  a  QoS  parameter  from  one  to 
another,  or  have  effect  on  a  QoS  parameter  by  cooperation 
between  each  other.  Eor  multiple  decisions  after  a  specific 
segment  of  a  dataflow,  multiple  segments  will  be  generated 
and  flow  to  corresponding  (sets  of)  components.  Einally, 
various  dataflows  (also  called  QoS  systemic  paths),  and  the 
sequences  of  the  segments  of  dataflows,  will  be  generated 
as  a  tree  structure  by  different  decisions.  Namely,  the  leaves 
of  the  tree  are  all  possible  assembled  cases  created  based  on 
different  decisions.  However,  the  dataflow  analysis  is  not 
sufficient  for  analyzing  DRE  systems,  because  some  QoS 
analyses  require  additional  information.  Eor  example,  in 
some  DRE  systems,  the  performance  of  the  systems  relies 
on  the  levels  of  QoS  to  be  achieved.  Different  levels  of 
QoS  will  trigger  corresponding  events,  and  vice  versa.  Eur- 
thermore,  time  and  priority  constraints  also  influence  QoS. 
All  of  these  characteristics  show  the  difficulty  for  dataflow 
analysis  to  assure  QoS  requirements  of  DRE  systems. 


A  Petri  Net  is  a  formalism  similar  to  dataflow  analysis, 
but  has  additional  abstractions  beneficial  in  modeling  con¬ 
current  and  asynchronous  systems  [14].  It  is  expressed  by 
a  Petri  Net  graph,  which  is  a  visual  representation  that  can 
model  a  DRE  system.  A  Petri  Net  graph  consists  of  abstrac¬ 
tions  adequate  to  analyze  QoS  requirements  of  possible  as¬ 
sembled  cases  of  a  DRE  system.  Tokens  represent  QoS  pa¬ 
rameters  with  the  identifiers,  and  the  types  and  ranges  of  the 
parameters.  Places,  (sets  of)  components  in  a  DRE  system, 
are  the  same  as  the  starting  and  end  points  of  a  segment  of  a 
dataflow  in  the  dataflow  analysis.  Flows,  same  as  dataflows, 
control  the  flowing  direction  of  the  QoS  parameters.  Transi¬ 
tions  embody  associated  predicates  and  functions  for  time, 
priorities  and  event  triggers  to  determine  what,  when  and 
how  QoS  parameters  are  to  be  processed  [14]:  only  when 
specific  conditions  are  satisfied  can  the  QoS  parameter  be 
processed  by  descendent  components. 


Figure  1.  The  Petri  Net  graph  and  its  reacha- 
biiity  tree  exampie. 

To  explore  various  possible  assembled  cases,  the  reacha¬ 
bility  tree  is  exploited  to  diagnose  a  Petri  Net  graph.  Eigure 
1  (a)  is  a  simple  Petri  Net  that  shows  the  formalism  to  model 
a  DRE  system  with  various  design  decisions  and  time  and 
event  concerns  described  below.  Assume  that  eight  com¬ 
ponents  (CO  to  C7)  constitute  a  simple  DRE  system.  Both 
Cl  and  C2  have  two  decisions  such  that  Cl  can  either  work 
with  CO  or  C2,  and  C2  can  cooperate  with  Cl  or  C3.  A 
QoS  parameter  (black  token)  that  processes  Cl  and  C2  will 
be  accessed  by  both  C5  and  C6.  C4,  C5  and  C6,  and  C7 
can  deal  with  the  QoS  parameter  at  time  tl,  t2  and  t3,  re¬ 
spectively.  Cl  and  C2  with  two  flows  means  the  token  will 
stream  to  one  of  two  transitions  without  preference  (i.e.,  al¬ 
ternative  decisions).  Einally,  transition  B  and  C  verify  if 
C2  has  an  event  (gray  token)  execution  that  triggers  C5  and 
C6  to  access  the  QoS  parameter.  Eor  B,  three  conditions 
cause  the  black  token  stream  to  C5  and  C6:  the  black  to¬ 
kens  in  Cl  and  C2  are  both  flowing  in;  the  gray  token  in 
C2  is  flowing  in,  and  is  verified  by  B;  and  timer  is  at  time 
t2.  Consequently,  one  assembled  case  is  made,  and  branch 
1  of  Eigure  1  (b)  is  constructed  correspondingly.  Eigure  1 
(b)  is  the  reachability  tree  of  Eigure  1  (a)  generated  by  the 
construction  principles  stated  above.  The  purpose  of  a  Petri 
Net  is  to  explore  and  generate  possible  assembled  cases  by 
its  reachability  tree  based  on  the  design  decisions,  selected 


components  considering  priorities,  events,  and  time. 

There  are  several  advantages  to  modeling  DRE  systems 
using  Petri  Nets.  First,  as  stated  before,  Petri  Nets’  abstrac¬ 
tions  and  characteristics  are  appropriate  to  simulate  DRE 
systems,  either  for  functional  or  nonfunctional  require¬ 
ments.  They  overcome  the  insufficiency  of  the  dataflow 
analysis.  In  addition,  the  transitions  regarding  priority,  time, 
and  events  infer  the  concept  of  dynamic  decision  making 
such  that  only  when  a  specific  transition  is  persuaded  can 
an  assembled  case  by  the  decision  be  generated. 

2.1.2  Aspect! 

AspectJ  [8]  is  an  aspect-oriented  programming  (AOP)  lan¬ 
guage  [9]  for  Java.  It  provides  a  modular  mechanism  to 
avoid  the  error-prone,  fragile  and  tedious  modification  work 
for  constraint  analysis.  An  aspect  recognizes  the  points  of 
the  method  crosscutting  Java’s  classes  using  pointcuts,  and 
then  defines  how  the  modification  should  be  made  using  ad¬ 
vice.  The  aspect  code  is  weaved  into  the  Java  base  code 
with  good  modularity  such  that  any  change  of  the  modifi¬ 
cation  is  isolated  in  the  aspect.  Hence,  AspectJ  promotes 
a  better  means  to  modularize  and  reuse  the  source  code. 
QoS-UniFrame  exploits  AspectJ  to  recognize  the  methods 
of  the  reachability  tree  construction,  and  insert  the  con¬ 
straint  analysis  method  code. 

2.2  Related  Work 

An  Ordered  Binary  Decision  Diagram  (OBDD)  [2]  ap¬ 
plies  symbolic  representations  (i.e.,  binary  encodings)  to 
prune  off  the  unsatisfactory  design  spaces  [13].  It  encodes 
mode  space  (i.e.,  functional  behaviors  that  QoS-UniFrame 
does  not  cover),  configuration  space  (i.e.,  dataflow),  and 
constraints  into  binary  representations.  Binary  operations 
are  used  to  compute  the  fulfillment  of  constraints.  How¬ 
ever,  the  OBDD  method  suffers  from  the  following  disad¬ 
vantages.  First,  binary  operations  for  addition  and  multi¬ 
plication  are  rigid  and  not  user-friendly.  It  is  not  easy  for 
system  analysts  to  adjust  the  evaluation  of  pruning  design 
spaces  adaptively.  In  addition,  this  binary  method  requires 
sufficient  temporary  variables  for  computation.  Second, 
many  of  the  QoS  parameters  are  non-orthogonal  such  that 
adjustment  of  one  QoS  parameter  may  substantially  affect 
other  QoS  parameters.  It  is  hard  to  specify  a  composite  non- 
orthogonal  constraint  by  means  of  conjunction  and  disjunc¬ 
tion.  A  quantitative  expression  (e.g.,  a  linear  or  nonlinear 
function)  would  be  a  better  alternative.  Third,  the  OBDD 
representation  is  not  mature  enough  to  solve  system-level 
constraint  problems  and  “the  scalability  of  the  method  be¬ 
comes  susceptible  and  results  in  an  exponential  blow-up  in 
OBDD  representation”  [13].  Most  importantly,  OBDD  is  a 
static  design  space  pruning  approach  such  that  the  computa¬ 
tion  can  be  processed  when  a  dataflow  with  corresponding 
constraints  is  entirely  constructed.  All  of  these  disadvan¬ 
tages  motivate  the  development  of  QoS-UniFrame. 


There  has  been  considerable  research  to  validate 
scheduling  requirements  of  DRE  systems.  In  [3],  the  timing 
constraint  is  validated  by  a  symbolic  model  checking  ap¬ 
proach.  Symbolic  model  checking  is  an  extension  of  model 
checking  such  that  analysis  is  based  on  symbolic  transition 
representation  and  propositional  logic  with  the  extension  of 
time  operators.  In  [4]  and  [6],  specialized  Petri  Nets  were 
applied  to  verify  time  behaviors  of  DRE  systems.  All  assur¬ 
ance  by  either  model  checking  or  Petri  Nets  has  an  inherent 
problem  that  validation  does  not  always  guarantee  that  the 
actual  synthesized  DRE  systems  are  perfectly  satisfactory: 
unpredictable  behaviors  that  sometimes  occur  in  DRE  sys¬ 
tems  degrade  the  confidence  of  validation.  Therefore,  sup¬ 
portive  statistical  references  utilized  by  QoS-UniFrame  will 
be  valuable  as  unpredictable  behaviors  occur. 

3  QoS-UniFrame 

Before  the  details  of  QoS-UniFrame  are  addressed,  a 
brief  example  is  given  to  illustrate  why  and  how  QoS- 
UniFrame  solves  the  design  space  exploration  problem  with 
the  constraint  satisfaction: 

A  water  treatment  plant  requires  deploying  new  treat¬ 
ment  units  (TUs)  to  two  new  water  treatment  pools.  Under 
the  limit  of  the  budget,  the  system  and  deployment  engineers 
would  like  to  ascertain  the  best  performance  of  collective 
TUs  from  the  blueprint.  During  the  system  design  stage, 
different  design  and  deployment  decisions  are  made  such  as 
the  order  and  the  priority  of  the  TUs,  and  the  locations  of 
the  specialized  TUs.  In  addition,  the  deployment  of  the  TUs 
has  various  restrictions  such  as  the  bandwidth  and  the  sig¬ 
nal  strength  of  the  wireless  network,  the  life  of  a  battery  in 
each  TU,  and  the  processing  speed  of  the  CPU  in  each  TU. 

Numerous  decisions  and  constraints  require  concentra¬ 
tions  in  this  project,  and  many  of  them  have  mutual  effects. 
Hence,  a  manual  procedure  to  construct  and  manage  this 
project  is  error-prone  and  tedious.  QoS-UniFrame  answers 
these  requests  to  ease  the  workload  of  the  design  decisions 
with  constraints  of  the  project.  Starting  from  functional  and 
nonfunctional  requirements,  a  use  case  scenario  is  analyzed 
to  determine  the  static  and  dynamic  QoS  requirements.  Sys¬ 
tem  engineers  construct  a  visual  Petri  Net  model  according 
to  their  design  and  deployment  decisions.  The  system  engi¬ 
neers  depict  the  mutual  behaviors  of  each  component  based 
on  their  QoS  parameters  in  the  Petri  Net  model.  System  an¬ 
alysts  write  the  AspectJ  codes  with  respect  to  the  evaluation 
of  strict  or  orthogonal  static  constraints  (defined  later),  such 
as  the  total  capacity  of  the  batteries  of  TUs.  These  aspects 
are  weaved  into  a  dynamic  and  parallel  approach  to  gen¬ 
erate  a  tree  abstraction  including  all  feasible  cases.  Back¬ 
tracking  and  branch-and-bound  algorithms  are  employed  to 
prune  off  infeasible  assembled  cases  based  on  strict  or  or¬ 
thogonal  static  QoS  requirements  at  the  first  level.  System 


analysts  then  write  a  domain-specific  scripting  code  of  evo¬ 
lutionary  algorithms.  The  source  code  takes  non-orthogonal 
or  non-strict  static,  and  dynamic  QoS  (defined  later)  into  ac¬ 
count  with  specific  mathematical  functions.  The  evolution¬ 
ary  algorithms  will  generate  statistical  results  automatically. 
The  less  probable  cases  will  be  eliminated  according  to  the 
discarding  policies  written  in  the  domain-specific  scripting 
code.  The  survival  cases  will  be  stored  back  to  the  knowl¬ 
edge  base  with  their  statistical  information.  Figure  2  shows 
the  framework  of  QoS-UniFrame. 


lines)  allow  margins  of  error  when  meeting  QoS  require¬ 
ments.  The  performance  of  the  system  will  be  degraded  ac¬ 
cording  to  the  magnitude  that  non-strict  QoS  requirements 
are  not  assured.  Orthogonal  QoS  implies  that  its  adaptation 
will  not  influence  other  QoS,  yet  non-orthogonal  QoS  sub¬ 
stantially  affects  other  QoS  directly  or  indirectly.  According 
to  the  hierarchy  of  classification,  QoS-UniFrame  separates 
static  and  dynamic  QoS  into  a  two-level  assurance  process. 

3.2  Petri  Net-based  QoS  Modeling 
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Figure  2.  The  framework  of  QoS-UniFrame. 

3.1  Classification  of  QoS  Parameters 

QoS-UniFrame  currently  concentrates  on  those  QoS  re¬ 
quirements  that  can  be  quantified.  Namely,  non-quantifiable 
QoS  requirements  (e.g.,  security  and  reliability)  are  out  of 
our  scope.  QoS-UniFrame  further  classifies  quantifiable 
QoS  requirements  into  static  and  dynamic.  Static  QoS  is 
design-related,  and  dynamic  QoS  is  substantially  influenced 
by  the  deployment  environment.  Many  of  the  static  QoS  re¬ 
quirements  can  be  evaluated  at  component  assembly  time, 
yet  dynamic  QoS  requirements  need  either  simulators  or 
virtual  machines  to  monitor,  predict,  and  adapt  the  QoS  con¬ 
cerns.  However,  several  dynamic  QoS  requirements  can  be 
assessed  by  referring  to  a  component’s  previous  state  and 
observations,  as  stored  in  a  knowledge  base  at  assembly 
time.  Static  and  dynamic  QoS  parameters  may  be  further 
subclassified  into  strict  and  non-strict,  and  orthogonal  and 
non-orthogonal  QoS.  Strict  QoS  requirements  (e.g.,  hard 
deadlines)  force  DRE  systems  to  meet  the  requirements. 
Otherwise,  the  system  will  be  incorrect  because  it  cannot 
meet  its  QoS.  Non-strict  QoS  requirements  (e.g.,  soft  dead¬ 


In  order  to  explore  design  spaces  efficiently  and  assure 
QoS  requirements  manageably,  a  formal  approach  to  model 
and  analyze  the  components  of  a  DRE  system  with  respect 
to  its  QoS  is  necessary:  a  Petri  Net-based  QoS  modeling 
language  has  been  created  in  the  Generic  Modeling  Envi¬ 
ronment  (GME)  [10]. 


public  aspect  Analysis  { 

pointcut  Monitor (QosPar  par)  : 

call (public  void  * . createNode  ( . . ) )  &&  args  (par) ; 
after  (QosPar  pari)  :  Monitor (pari ) 

{  double  temp=0; 

if  (pari . getName ( ) . equals ( "MPC" ) )  { 

//MPC  stands  for  "Maximum  Flow  Processing  Capacity" 
temp=parl . get Value ( ) ; 

//evaluate  MPC' s  QoS  requirement  } 

} 

after  (QosPar  par2)  :  Monitor (par2 ) 

{  double  temp=0; 

if  (par2 . getName ( ) . equals ( "BL" ) )  { 

//BL  stands  for  "Battery  Life" 
temp=parl . getValue  () ; 

//evaluate  BL' s  QoS  requirement  } 

} 

} 


Figure  3.  Constraint  anaiysis  method  code  for 
QoS  parameters  written  in  AspectJ. 

As  stated  before,  a  Petri  Net  can  explore  and  produce  de¬ 
sign  spaces  using  the  reachability  tree.  QoS-UniFrame  eval¬ 
uates  strict  or  orthogonal  static  QoS  requirements  as  a  child 
node  of  a  reachability  tree  is  generated,  and  remove  infeasi¬ 
ble  child  nodes.  Thus,  strict  or  orthogonal  static  constraint 
analysis  methods  crosscut  the  source  code  of  the  child  node 
construction  of  the  reachability  tree.  The  source  code  that 
analyzes  constraints  is  written  in  AspectJ  [8]  as  shown  in 
Figure  3,  and  is  weaved  into  the  source  code  of  the  child 
node  construction.  In  Figure  3,  pointcut  “Monitor”  recog¬ 
nizes  the  method  that  generates  a  child  node  of  the  reach¬ 
ability  tree.  The  first  after  advice  statement  evaluates  the 
maximum  flow  processing  capacity  (MPC).  It  shows  that 
after  the  “createNode”  method  is  called,  the  QoS  parameter 
is  accessed,  and  then  is  evaluated  by  bounding  and  criterion 
functions  (defined  later).  The  second  after  advice  statement 
evaluates  the  battery  life  (BL)  using  different  bounding  and 
criterion  functions  after  the  “createNode”  method  is  called. 

Implementing  Petri  Nets  with  GME  and  AspectJ  con¬ 
tributes  several  merits.  Because  GME  is  a  metaconfigurable 
modeling  tool  that  permits  customization  [10],  Petri  Net 
models  (i.e.,  simulation  of  DRE  systems)  can  extend  new 


features  easily.  Clear  and  appropriate  syntactical  and  se¬ 
mantic  design  constraints  supported  in  GME  moderate  the 
possibility  of  the  errors  occuring  at  the  design  phase.  The 
visual  modeling  environment  of  GME  also  provides  a  user 
friendly  and  easily  manageable  environment  for  system  en¬ 
gineers.  In  addition,  separation  of  concerns  of  construction 
of  QoS  systemic  paths  and  constraint  analysis  methods  pro¬ 
motes  reusability  and  modularity  of  source  code.  Various 
orthogonal  QoS  parameters  can  be  evaluated  concurrently 
by  writing  different  advice  in  the  analysis  aspect  (Eigure  3). 
In  this  context,  concurrency  means  that  all  of  the  constraint 
analysis  codes  are  embedded  in  a  child  node  construction 
method;  namely,  all  advice  crosscuts  the  same  pointcut. 
Thus,  it  is  necessary  to  define  the  advice  precedence  (i.e., 
weaving  order  of  the  advice)  to  avoid  conflicts. 

3.3  Backtracking  and  Branch-and-bound 

In  order  to  decrease  the  design  spaces  dynamically,  the 
reachability  tree  construction  code  and  its  analysis  aspect 
(Eigure  3)  are  embedded  into  backtracking  or  branch-and- 
bound  (B/B)  algorithms  [7].  The  B/B  algorithm  that  QoS- 
UniErame  exploits  is  the  first  level  assurance  to  evaluate  sta¬ 
tic  QoS  parameters  that  are  strict  and  orthogonal,  as  in  [13]. 
The  backtracking  algorithm  employs  a  depth-first  search  on 
the  reachability  tree  structure  with  bounding  and  criterion 
functions.  Bounding  functions  are  the  constraints  of  strict 
and  orthogonal  static  QoS  requirements,  and  criterion  func¬ 
tions  (i.e.,  QoS  utility  functions)  are  used  to  determine  the 
optimal  solutions  of  a  QoS  systemic  path,  either  maximal  or 
minimal.  The  backtracking  algorithm  constructs  the  reach¬ 
ability  tree  from  the  root  by  depth-first  search.  It  evaluates 
the  bounding  and  criterion  functions  at  every  intermediate 
node.  If  the  criterion  applied  to  certain  nodes  does  not  meet 
the  bounding  function,  the  backtracking  algorithm  will  stop 
generating  all  descendant  nodes.  Alternatively,  the  branch- 
and-bound  algorithm  operates  with  the  reachability  tree  us¬ 
ing  various  search  algorithms.  LC-search  [7]  is  an  improved 
search  algorithm  with  a  ranking  function  QoS-UniErame 
chooses  to  implement.  Similarly,  the  branch-and-bound  al¬ 
gorithm  traces  from  the  root  of  a  reachability  tree.  The  rank¬ 
ing  function  determines  the  next  node  (i.e.,  live  node)  to 
be  evaluated.  LC-search  intelligently  ranks  the  live  nodes 
to  avoid  the  fixed  order  searches.  Bounding  and  criterion 
functions  in  the  backtracking  algorithm  play  the  same  roles 
to  stop  constructing  unsatisfactory  child  nodes.  Therefore, 
the  B/B  algorithm  dynamically  eliminates  the  unsatisfactory 
design  spaces  based  on  strict  and  orthogonal  static  QoS  re¬ 
quirements.  Unlike  most  pruning  design  space  approaches, 
such  as  [13],  that  evaluate  one  design  space  at  a  time,  the 
B/B  algorithm  introduces  a  “parallel  pruning  concept”  that 
cuts  infeasible  descendant  leaves  concurrently;  namely,  all 
the  child  nodes  of  an  unsatisfactory  intermediate  node  are 
discarded  at  the  same  time,  which  means  infeasible  design 


spaces  are  eliminated  simultaneously. 

3.4  Evolutionary  Algorithms 

In  the  DRE  domain,  it  is  tedious  and  time-consuming 
to  validate  one  QoS  requirement  at  a  time.  The  B/B  al¬ 
gorithm  processes  various  strict  and  orthogonal  static  QoS 
parameters  simultaneously  writing  different  advice  in  an  as¬ 
pect.  Eor  non-strict  or  non-orthogonal  static  QoS  require¬ 
ments,  and  dynamic  QoS  requirements,  QoS-UniErame  uti¬ 
lizes  evolutionary  algorithms  (EAs)  [12]  as  the  second  level 
assurance.  An  EA  is  a  search  and  optimization  technique 
based  on  the  principles  of  natural  selection  and  survival  of 
the  fittest  [12].  The  decision  of  the  fittest  (i.e.,  maximum, 
minimum  or  average)  comes  from  the  results  of  linear  or 
nonlinear  fitness  functions  in  EAs.  The  fitness  functions 
solve  the  tedious  and  time-consuming  problem  of  non-strict 
static  QoS,  and  the  side  effect  problem  of  non-orthogonal 
(static  and  dynamic)  QoS  by  combining  all  of  the  associated 
QoS  requirements  into  a  mathematical  formula.  Because 
dynamic  QoS  requirements  need  to  comply  with  the  deploy¬ 
ment  environment,  QoS-UniErame  processes  static  and  dy¬ 
namic  QoS  requirements  in  separate  steps.  QoS-UniErame 
has  developed  a  domain-specific  scripting  language,  called 
PPCea  [1 1],  to  make  EAs  expeditious  and  adaptable.  PPCea 
and  AspectJ  express  the  assurance  of  QoS  requirements  by 
means  of  linear  or  nonlinear  functions.  These  representa¬ 
tions  make  the  assurance  process  easier  to  scale  than  the 
OBDD  approach  at  system  assembly  time. 

3.4.1  Static  QoS  Requirements 

The  B/B  algorithm  is,  in  fact,  able  to  evaluate  non- 
strict/non-orthogonal  static  QoS  requirements  by  AspectJ. 
However,  the  unique  purpose  of  the  B/B  algorithm  is  to  re¬ 
move  infeasible  design  spaces  with  the  dynamic  and  paral¬ 
lel  concept.  Hence,  we  postpone  computing  non-strict/non- 
orthogonal  static  QoS  until  the  second  level  assurance.  An 
EA  evaluates  the  best  results  of  non-strict/non-orthogonal 
static  QoS  parameters  by  a  user-defined  fitness  function. 
Eor  example,  a  DRE  system  constructed  by  a  set  of  PDAs 
that  meets  battery  maximum  capacity  may  estimate  the  op¬ 
timal  solution  of  the  lifetime,  the  disposal  fee,  and  the  pur¬ 
chase  cost  of  the  batteries  by  a  fitness  function.  Therefore, 
a  user-defined  fitness  function  can  satisfy  this  demand. 

3.4.2  Dynamic  QoS  Requirements 

Evaluating  dynamic  QoS  requires  the  cooperation  of  the  de¬ 
ployment  environment.  However,  the  statistical  results  of 
dynamic  QoS  by  EAs  at  component  assembly  time  may 
serve  as  excellent  estimates  and  as  substitutions  as  unpre¬ 
dictable  behaviors  occur  later  at  runtime.  EA  solves  the 
best,  worst,  and  average  fitness  values  and  their  standard 
deviations  of  a  user-defined  fitness  function.  Dynamic  QoS 
requirement  validation,  such  as  deadlines  for  real-time  sys¬ 
tems,  uses  the  previous  state  information  of  a  component  in 


the  knowledge  base  to  obtain  the  statistical  results.  Some 
assembled  cases  of  these  statistical  results  can  be  the  refer¬ 
ences  of  runtime  validation  evaluation,  and  others  may  be 
eliminated  by  discarding  policies  invented  based  on  PPCea. 
User-defined  discarding  policies  determine  how  and  which 
assembled  cases  are  rejected.  More  details  will  be  explained 
in  the  next  subsection. 

3.4.3  PPCea 

To  obtain  the  statistical  outputs  from  EAs  efficiently  and  to 
discard  less  probable  assembled  cases  flexibly,  a  domain- 
specific  scripting  language.  Programmable  Parameter  Con¬ 
trol  for  Evolutionary  Algorithms  (PPCea)  [11],  has  been 
developed.  PPCea  keeps  the  evolution  process  simple  and 
raises  the  control  parameter  settings  up  to  a  high  abstrac¬ 
tion  level  in  a  programming  fashion.  In  PPCea,  a  configu¬ 
ration  mechanism  is  provided  to  embed  the  parameters  of 
EAs  (e.g.,  crossover,  mutation  and  discard  rate,  and  popu¬ 
lation  size)  and  its  fitness  function  into  the  computation  of 
EAs.  The  modification  of  these  parameters  is  by  a  program¬ 
ming  fashion,  i.e.,  assignment  statement.  This  mechanism 
provides  the  flexibility  for  users  to  find  the  optimal  solution 
by  different  kinds  of  parameter  settings  [11]. 


genetic 

Discard  :=  1.1;  //discard  rate  by  parameter  tuning 

while  (t  <=  10)  do 

init;  //initialize  population 

call_EA; //evaluate  fitness  value  for  a  population 
Temp  :=  Temp  +  Worst; //Temp  is  temporary  variable 
t  :=  t  +  1 

end; 

Temp  :=  Temp  /  t; 
if  (Temp  >  QoS*Discard) 

//Avg  of  Worst  value  far  from  requirement 
delete_gene  //delete  test  cases  not  satisfied 

fi; 

end  genetic 


Figure  4.  Parameter  tuning  discarding  poiicy 
written  in  PPCea 

After  defining  the  fitness  function  and  parameters, 
PPCea  decides  which  genotypes  (i.e.,  assembled  cases) 
should  be  deleted  from  the  population  by  the  discarding 
policies  with  their  discard  rates.  Users  can  apply  parameter 
tuning,  deterministic,  or  adaptive  [5]  discarding  policies  to 
the  discard  rate.  Parameter  tuning  determines  the  value  of 
the  discard  rate  by  assigning  a  constant  value  before  each 
EA  run.  The  deterministic  method  assigns  the  discard  rate 
before  the  evaluation  by  a  deterministic  rule  based  on  linear 
algebra  [11].  Einally,  the  adaptive  method  adjusts  the  dis¬ 
card  rate  during  the  run  of  evaluation  [11].  Eigure  4  shows 
the  example  of  parameter  tuning  discarding  policy  that  op¬ 
erates  with  the  discard  rate,  “t”  is  the  counter  for  the  while 
loop;  “Discard”  is  the  discard  rate  for  discarding  policy; 
“QoS”  is  a  dynamic  QoS  requirement;  “Worst”  is  the  worst 
fitness  value;  “Temp”  is  the  temporary  variable  for  the  con¬ 
venience  of  computation;  “call_EA”  evaluates  the  values  of 
fitness  function  of  each  genotype;  and  “delete_gene”  dis¬ 
cards  those  genotypes  that  do  not  meet  the  requirements.  In 


Eigure  4,  if  the  average  of  ten  worst  cases  is  greater  than 
1.1  (i.e.,  user-defined  discard  rate)  times  the  strict  dynamic 
QoS  requirement,  the  test  case  can  be  rejected. 

4  A  DRE  System  Case  Study 

This  section  presents  a  Petri  Net-based  QoS  model  of  an 
example  DRE  system  representing  the  water  treatment  plant 
described  in  section  3.  The  system  engineers  would  like  to 
examine  the  best  performance  of  the  water  treatment  ability 
under  certain  constraints: 

(a)  Due  to  the  budget  constraint,  only  three  and  two  treat¬ 
ment  units  can  be  chosen  for  pools  one  and  two  for  the 
water  treatment  process,  respectively. 

(b)  the  total  maximum  flow  processing  capacity  is  at  least 
50  million  gallons  per  day. 

(c)  the  battery  life  of  each  TU  has  at  least  15  hours  left. 

(d)  total  CPU  usage  is  at  most  70  percent. 

(e)  total  water  treatment  volume  of  selected  TUs  is  at  least 
35  million  gallons  per  day. 

(f)  Pipeline  A  must  pump  water  into  Pool  Two  at  time  tl ; 
Pipeline  B  and  C  must  pump  water  into  Tower  X  and  Y 
at  time  t2,  respectively. 

Table  1 .  The  values  of  QoS  parameters  of  the 
water  treatment  plant  example 


TU 

MPC 

BL 

CPU  usage 

WTV 

Cll 

10 

20 

(20,23) 

(5,8) 

C12 

15 

14 

(10,12) 

(10,12) 

C13 

13 

17 

(15,18) 

(10,12) 

C14 

15 

22 

(5,7) 

(8,10) 

C21 

16 

28 

(10,15) 

(5,9) 

C22 

18 

33 

(15,18) 

(4,7) 

C23 

20 

20 

(20,22) 

(7,10) 

Constraint  (a)  is  a  restriction  of  the  design  decision.  Con¬ 
straints  (b)  and  (c)  are  the  strict  and  orthogonal  static  QoS 
parameters.  Constraints  (d)  and  (e)  are  the  dynamic  QoS 
parameters.  Constraint  (f)  is  the  time  constraint.  Table  1 
includes  all  of  the  values  of  the  QoS  parameters  requested 
from  the  knowledge  base.  Column  1  shows  the  identity  of 
each  treatment  unit  (TU),  column  2  contains  the  maximum 
flow  processing  capacity  (MPC)  of  each  TU  (million  gal- 
lons/day),  column  3  shows  the  current  battery  life  (BE)  of 
each  unit  (voltage),  column  4  is  the  CPU  usage  of  each  TU 
(%),  and  the  last  column  contains  the  water  treatment  vol¬ 
ume  (WTV)  of  each  TU  (million  gallons/day).  Eigure  5 
shows  the  Petri  Net  model  of  the  project  under  constraints 
(a)  and  (f).  The  bars  (i.e.,  transitions)  at  the  same  level  of 
tO,  tl  and  t2  horizontally  have  the  mechanism  of  the  timing 
control. 

QoS-UniPrame  generates  a  reachability  tree  of  the 
project  based  on  strict  and  orthogonal  static  QoS.  During 
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Figure  5.  The  example  of  the  Petri  Net  modei 
representing  the  water  treatment  piant. 

Tabie  2.  The  experimentai  resuits  of  the  water 
treatment  piant  project 


Case  1 

Case  2 

Case  3 

CPU  Average 

69.8223 

73.9332 

77.4793 

CPU  Worst 

64.1087 

75.0327 

78.4904 

WTV  Average 

40.7911 

43.25 

42.107 

WTV  Worst 

36.2826 

39.4127 

37.1191 

NO  Best 

11.8349 

10.4933 

11.215 

NO  Average 

11.3491 

10.1158 

10.6731 

NO  Worst 

9.483 

8.4471 

8.9652 

the  first  level  assurance,  two  after  advice  statements  from 
Figure  3  are  written  and  weaved  into  the  source  code  of 
the  tree  construction.  The  first  advice  examines  the  sat¬ 
isfaction  of  the  constraint  (b),  and  the  second  advice  as¬ 
sures  the  constraint  (c).  From  the  experimental  result,  QoS- 
UniFrame  shows  that  C12  does  not  meet  the  constraint  (c). 
Thus,  only  Cll,  C13,  C14,  C21,  C22  and  C23  will  be 
chosen  for  pool  one  and  pool  two.  At  this  stage,  three 
assembled  cases  have  survived;  {C11,C13,C14,C21,C22}, 
{C11,C13,C14,C21,C23},  and  {C11,C13,C14,C22,C23}. 
Subsequently,  the  CPU  usage  and  water  treatment  volume 
(WTV)  require  the  previous  states  and  observations  stored 
in  the  knowledge  base.  Table  1  contains  the  boundaries 
of  the  dynamic  QoS  requirements.  At  the  second  level, 
the  parameter  tuning  approach  written  in  PPCea  code  is 
involved  (Figure  4).  First,  two  dynamic  QoS  constraints 
are  examined  independently  by  using  addition.  The  prede¬ 
fined  discard  rate  is  1.1,  which  means  if  the  worst  case  is 
greater  than  1.1  times  this  strict  dynamic  QoS  requirement, 
the  evaluated  case  is  deleted.  All  of  the  predefined  values 
of  parameters  needed  for  EAs  are  in  Table  2.  “Discard” 


is  defined  in  section  3.4.3.  “Maxgen”  is  the  maximum 
number  of  generations  (100)  an  EA  can  run.  “Popsize” 
is  the  size  of  a  population  (value  100),  “Pxover”  is  the 
crossover  rate  (0.5),  and  “Pmutation”  is  the  mutation  rate 
(0.7)  [12].  Please  note  that,  for  brevity,  only  one  parame¬ 
ter  setting  is  represented  in  the  paper.  To  obtain  the  best 
statistical  results,  a  fitness  function  can  be  evaluated  with 
various  parameter  settings  in  a  programmable  fashion  dur¬ 
ing  the  execution  of  PPCea  code  [11].  Table  2  contains 
the  average  results  of  each  case  after  ten  iterations  at  the 
second  level.  Case  1  represents  {Cl  1,C13,C14,C21,C22}, 
case  2  expresses  (Cl  1,C13,C14,C21,C23},  and  case  3 
is  {C11,C13,C14,C22,C23}.  “NO”  stands  for  the  non- 
orthogonal  fitness  function  described  below.  Table  2  shows 
that  {Cl  l,C13,C14,C22,C23}’s  average  of  ten  worst  cases 
is  bigger  than  1.1  times  the  constraint  (d).  Therefore,  QoS- 
UniPrame  tends  to  discard  this  design  space.  Case  3  does 
not  meet  the  discarding  policy,  so  QoS-UniErame  keeps  its 
information  for  future  use.  Because  CPU  usage  and  water 
treatment  volume  are  non-orthogonal  dynamic  QoS  para¬ 
meters,  we  defined  a  fitness  function  to  address  the  mutual 
effect  of  CPU  usage  and  water  treatment  volume.  The  fit¬ 
ness  function  is  defined  as  below: 

f{x)  =  {CPU  U sage) / {W ater  Treatment  Volume) 

This  function  is  treated  as  the  statistical  references  for 
future  investigation  instead  of  a  constraint.  Einally, 
{C11,C13,C14,C21,C23}  and  {Cl  1,C13,C14,C21,C22} 
are  two  survival  cases  statistically  based  on  Eigure  4. 


Figure  6.  The  Petri  Net  reachabiiity  tree  of  the 
water  treatment  piant  exampie. 

These  experimental  results  show  that  QoS-UniErame 
outperforms  the  OBDD  approach  [13]  in  the  example  of 
the  water  treatment  plant  project.  At  the  first  level,  QoS- 
UniErame  cuts  off  3  intermediate  nodes,  as  shown  in  Eigure 
6.  Each  of  these  intermediate  nodes  have  three  more  child 
nodes.  Therefore,  9  more  design  spaces  are  eliminated  be¬ 
fore  the  end  of  reachability  tree  construction.  The  OBDD 
method,  however,  requires  generating  all  12  cases  which 
is  less  efficient  than  QoS-UniPrame.  In  addition,  by  using 
the  discarding  policy  at  the  second  level,  PPCea  statistically 
discards  one  more  case.  Therefore,  QoS-UniPrame  has  bet¬ 
ter  performance  than  the  OBDD  approach  for  this  specific 
example. 


5  Conclusion  and  the  Future  Work 

The  earlier  that  an  error  is  detected  in  the  software  life- 
cycle,  the  less  costly  it  is  to  fix  [1].  QoS-UniFrame  obeys 
this  golden  rule  to  reduce  the  design  space  at  system  assem¬ 
bly  time.  At  the  first  level,  the  dynamic  and  parallel  pruning 
approach  is  applied  to  expedite  the  pruning  process.  Only 
the  feasible  QoS  systemic  paths  are  generated  by  back¬ 
tracking  or  branch-and-bound  algorithms.  At  the  second 
level,  a  fine-grained  statistical  approach  is  employed  to  fur¬ 
ther  eliminate  less  probable  QoS  systemic  paths.  PPCea 
also  provides  auxiliary  statistical  results  as  the  reference 
at  runtime.  In  addition,  constructing  Petri  Net-based  QoS 
modeling  in  the  GME  in  collaboration  with  Aspect!  facili¬ 
tates  customization,  extensibility,  flexibility,  modularity  and 
reusability.  In  conclusion,  QoS-UniFrame  provides  a  for¬ 
mal,  manageable,  scalable  and  semi-automatic  approach  to 
prune  off  unsatisfactory  design  spaces,  and  to  validate  a 
DRE  system  from  its  requirements  at  system  assembly  time. 
The  design  complexity  of  building  DRE  systems  complying 
with  numerous  decisions,  ordered  components,  events,  and 
time  can  be  further  reduced  than  the  OBDD  method.  Eor 
more  details  regarding  QoS-UniErame,  please  refer  to  [15]. 

QoS-UniErame  introduces  a  mathematical  method  (i.e., 
a  fitness  function)  to  solve  the  non-orthogonal  QoS  side 
effect  problem.  However,  this  approach  is  still  not  com¬ 
prehensive  and  further  research  is  necessary.  Eor  exam¬ 
ple,  the  priorities  of  the  non-orthogonal  QoS  and  the  de¬ 
gree  of  the  affectations  among  these  QoS  must  be  defined. 
Finally,  QoS-UniFrame  is  a  semi-automatic  toolkit  to  ex¬ 
plore,  decrease  and  then  assure  the  design  spaces  with  con¬ 
straints.  System  analysts  would  be  required  to  have  the  ba¬ 
sic  knowledge  of  programming  skills  in  Aspect!  and  PPCea. 
A  comprehensive  automatic  toolkit  of  design  space  explo¬ 
ration  and  assurance  that  eases  system  analysts  and  system 
engineers’  workload  is  also  the  future  direction  of  QoS- 
UniFrame. 
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